Pattern collections

These are structured collections of patterns that categorize and clarify patterns. It is an extremely helpful starting point for learning what new patterns are called and the theories behind them. One modern, comprehensive collection is UI patterns ( http://ui-patterns.com/patterns/ ), as shown in Figure 2-1.

Pattern galleries

Pattern galleries show, rather than tell, using examples from all sorts of web sites and apps. One example is pttrns ( https://pttrns.com ), as shown in Figure 2-2.

There are also many domain-specific galleries that focus on a single theme, like social interfaces or e-commerce. For example, see Mobile Patterns ( www.mobile-patterns.com ) for mobile-first and native app patterns, as shown in Figure 2-3.

Platform guidelines

Platform guidelines are well-tailored to the device type (mobile, laptop, wearables, etc.) and operating system (iOS, Android, Windows, etc.), more closely matching context to your needs. They’re also built up from decades of improvement, refinement, and lessons learned. Consider, for example, Apple’s iOS Human Interface Guidelines shown in Figure 2-4.

The stepper shown in Apple’s iOS guidelines is optimized for a touch device with a small screen.

As UI patterns are only relevant to a specific domain or context, these platform guidelines are only valuable insofar as they highlight the differences between platforms. Technological changes demand some push and pull, divergence and convergence, fragmentation and consolidation. We might expect movement toward cohesive cross-platform guidelines like Google’s Material Design guidelines ( https://material.io/design/guidelines-overview/ ) with more minimal guidance on platform adaptation.² For a striking example, the guidelines on edge swipes suggest “an edge swipe starts from outside of the screen to reveal off-screen content,” and yet it might conflict with other swipe gestures, such as horizontal swipes through pages. The guidelines further describe that when there are no gesture conflicts, Android edge swipes from the left will reveal off-screen content, while iOS will navigate back through an app’s hierarchy.

UI frameworks

UI patterns wouldn’t be much without code to bring them to life. UI or front-end frameworks offer invaluable starting points for developers to consider the implementation of the archetypal pattern and its core elements. Designers can also use these to explore all the different “states” they need to design. Figure 2-5 shows the Tachyons ( https://tachyons.io ) framework’s components section.

Of course, you should lean on your framework if you’re already using one, but sometimes you might draw from others to fill in the gaps. For example, Zurb Foundation framework³ provides styled switch and slider components that Bootstrap does not, while Bootstrap provides inline forms that Foundation does not (at the time of writing).

Pattern libraries, design systems, style guides, and anti-patterns

Public pattern libraries and style guides from other companies and brands help demonstrate how they solved specific problems for their specific market. Design systems often include component libraries that bring patterns to life. We’ll explore those further in Chapter 4. If you really want a head start, check out the Adele repository of publicly available design systems and pattern libraries ( https://adele.uxpin.com ).

Similarly, sometimes you can learn by counterexample—what not to do. Learn more in Chapter 5 on anti-patterns.

Inspiring visual style

Some folk are concerned about the dribbblisation of design⁴—the phenomenon of designs created to look good rather than solve real problems. I tend to believe the problem with dribbble⁵ is what we make of it. It’s only a platform; how we use it is up to us. It can be effective when used to test and stretch visual skills, encouraging designers to showcase and refine their visual designs as well as push the boundaries of what’s possible. Being removed from the constraints of real problems might help you design an efficient and satisfying experience.⁶ This can help drive innovation.

Next, we’ll explore some specific patterns helpful to onboarding to give you a feel for what they look like.

Pattern: Walkthrough

A walkthrough is a guided tour or demo of a feature or product. It’s presented in a specific order to every new user to introduce complex workflows or concepts.

The digital product design platform, InVision, makes heavy use of walkthroughs in their products, as you can see in Figure 2-6.

The crux of the walkthrough pattern is to literally walk the user through each step of their core task and then to direct their focus to only one step at a time and only steps critical to completing their task.

Show the actual features or steps—for example, using screenshots—to concretely identify them in the product so the user doesn’t need to remember what the feature was called and go looking for where that label might appear in the product. You needn’t explore every detail of how to use a feature, but at least indicate what the important features are and how they fit within the landscape. Each step needs to instruct and inform users so they can make decisions about whether and how to use your product. Figure 2-7 shows InVision’s prompt to add more screens.

This walkthrough prompt lets users know that prototypes are “best with two or more” screens, encouraging them to add at least one more, while reminding them where the button is to upload and sync screens.

By letting users navigate backward and forward through a walkthrough, as well as dismiss it, they can directly access the information of most interest to them. While your user is in the walkthrough, show a progress bar or indicator to represent where they are in the process. They may wish to be assured that it’s a short process containing only two more steps or otherwise keep track of which pieces of information they’ve seen already. For mission-critical walkthroughs that the user needs to see, such as a change in terms of use, password recovery, or recovery from a security compromise, you may need to ditch the additional navigation options.

Walkthroughs are a natural fit for first-time use. They’re handy for introducing new or complex concepts or workflows, so it’s important to make them available on the first page load, first site visit, first app open, and so on, considering if the user could have already seen the walkthrough on a different platform. A useful rule of thumb for when to employ a walkthrough is whenever the user may have doubts about the product.

Workflow walkthroughs

If your product is optimized for a specific workflow, introducing that workflow early on serves as signposting to help users understand how to navigate through the product and find more information when they need it. In Figure 2-8 you’ll find InVision make it clear what the different modes are in their product and where they can be found, so that you can switch through the modes at your leisure later, even though they are presented in the intended order:

Concept walkthroughs

If your product’s value proposition is disruptive and counterintuitive, use a walkthrough to break down the relevant concepts. For example, Airbnb needed to introduce their users to the share economy concept of renting out homes and apartments instead of using hotels. This brought a host of concerns for guests, such as if the place will be safe, and for hosts, such as if the property will be kept in good condition. To ease users’ concerns, Airbnb needed to guide new users through the concepts with reassuring illustrations and address specific friction points, as you can see in Figure 2-9.

To assure guests, Airbnb describes their online and offline safety measures, including risk scoring, watchlist and background checks, and preparedness safety workshops and free smoke detectors. Similarly, you can see in Figure 2-10 how Airbnb introduces hosts to their hosting process.

Airbnb first addresses how the host might be feeling: “sharing your space or passions with someone you’ve never met can feel like a leap of faith.” The prospective host can then see very clearly numbered steps to guide them through the process, with important explanatory details along the way.

A useful idea here is Nielsen Norman Group’s mental models⁷—what users believe about a system that might differ from the designer’s model. A user’s beliefs will affect how they use a product, so you might use a concept walkthrough to update the user’s mental model to bring it closer to how the system actually works.

Reserve walkthroughs for complex workflows and concepts. Instead of a walkthrough, see if you can break up the workflow further so that it’s simpler and more self-explanatory, or consider a playthrough instead.

Pattern: Playthrough

A playthrough is an interactive tutorial or warm up that lets a user learn by doing, in a safe environment such as a sandbox.

Figure 2-11 shows an example of TeuxDeux’s homepage playthrough.

TeuxDeux is a task management app. Their homepage playthrough shows a callout enticing visitors to resize the example app. The example app contains explicit instructions in its to-do items to click, hover, drag, and double-click different items, so you can “try before you buy.”

When a user wants to try your product’s features that are new to them, a playthrough provides a forgiving interface to let them explore safely and make mistakes without fear of repercussions. By stepping them through the product slowly, you can introduce features as needed and let them immediately play with them. There are two main scenarios for a playthrough: setup and sandbox.

Setup playthrough

Sometimes a playthrough is used as part of a setup process, for example, asking for a name, showing where it will be displayed, letting the user provide their name, then moving onto the next logical step in the product.

In Figure 2-12 you can see an empty state before the user has uploaded a cover image on their Facebook profile page.

Figure 2-13 shows an onboarding prompt to add a cover photo.

After the user adds a cover, Figure 2-14 shows an instruction to reposition the image with a live preview of how it will look to other users.

This illustrates how a user plays through the app to set up their profile.

Sandbox playthrough

A sandbox playthrough provides sample resources with instructions on how to use them. For example, TeuxDeux starts new users with a few pre-filled tasks that teach you how to use the app, just like their homepage.

Apple’s Swift Playgrounds epitomizes the playthrough pattern. It’s a whole app dedicated to being a sandboxed interactive tutorial to learning Swift, as shown in Figure 2-15.

When to use a playthrough

Playthroughs let users immediately interact with the core tasks. This aspect in particular separates playthroughs from walkthroughs, demos, and other instructional content. It’s an excellent opportunity to demonstrate the value of the feature without delay. Likewise, interactivity can improve the learning experience, so it feels easy.

Using this pattern to provide a sandbox can be handy when your product’s user wants to avoid “breaking real data.” For example, see InVision’s Freehand tutorial in Figure 2-16.

This lets people draw with wild abandon. They may be free from concern of losing their own work by trying out new Freehand features in the tutorial. You can see the user has an opportunity to ask for help to complete the step if they want to move on.

Once the user has completed the step (tried the feature), they’re given an option to move to the next step, as shown in Figure 2-17.

As with Walkthroughs, some people might want to navigate through your product via unexpected paths, so consider if you need to show an easy exit, such as a “Skip all” link or links to navigate backward through previous steps. In InVision’s Freehand example, there’s an option on every step to “Skip tutorial,” and on every Freehand, there’s an option to “Review tutorial.”

After a new user has played through your product’s features, make it easy to take off the training wheels. They’ve learned what they need to know, so provide an easy method to remove any unwanted sample data. It can be frustrating to find that sample data contributes to account limits, like the number of projects you’re allowed to have before upgrading. In InVision’s Freehand example, the tutorial lets the user play without creating a Freehand that could clutter up their account.

This pattern demonstrates how the context of the user’s place in their journey drastically changes the relevance of the pattern. If they were an expert user, these playthrough experiences might be infuriating. This is a reminder that patterns are solutions to problems in a context.

Playthroughs can be overkill when the consequences of exploring unguided are minimal. Avoid them if users can make trivial mistakes and recover from them without guidance. For example, the consequences of searching for the “wrong” term in a search function might result in useless results, but the user can easily type in a new search term—no guidance is needed.

Pattern: Newsletter signup

A newsletter signup is a form that allows users to subscribe to a list. They may then be sent email news about the product to keep them informed about regularly changing content.

Figure 2-18 shows an example of a newsletter signup.

There are strong conventions across the Web for email newsletter signup forms. Let’s look at their key elements.

• Label: Most newsletters provide an explicit “Email Address” label element to identify the component. Sometimes, it implied through a call to action. For example, on the newsletter signup section on the Bellroy web site for carry goods, there is the line: “Being In The Know Feels Great: Signup here for news and updates,” which you can see in Figure 2-19.

Use the newsletter signup pattern the first time a user wants to access email news. If they’ve already subscribed to your newsletter, avoid using this pattern. You can check if they’ve already subscribed before showing the signup form by examining their user account (if they are logged in) or by seeing if they have just come to your site by your newsletter. You can do this by or looking at the URL in the address bar (or in code by inspecting the HTML referer path⁹) to see if it includes tracking links from your newsletter such as /?utm_medium=email&utm_campaign=newsletter. If a visitor comes from your newsletter, don’t show the signup form.

Another time to avoid this pattern is if user’s email address is not subscribed to the newsletter list, but you already have their address for other reasons (such as account login). In this case, you could show an opt-in checkbox instead of asking them to type in their address again.

Let’s see another first-time signup pattern commonly seen with newsletter subscription: validation feedback.

Pattern: Validation feedback

Validation feedback is information shown to your user after they’ve provided data and you’ve processed it. The feedback might be a warning or suggestion, an error preventing further progress until it’s been fixed, or confirmation that the data was complete and correct. Validation feedback most often appears on forms.

Figure 2-21 shows validation feedback with a warning.

This example suggests the “Email address should follow the format user@domain.com.” Often a validation warning lets the user continue at their own peril.

Figure 2-22 shows validation feedback with an error.

This example shows the error message: “This email address looks fake or invalid. Please enter a real email address.” Usually an error prevents any further progress until it’s been corrected.

Figure 2-23 shows validation feedback indicating a soft confirmation.

This example says, “Thank you! You will receive a request to confirm your subscription.”, encouraging further action to be taken to finish the process.

Finally, Figure 2-24 shows validation feedback indicating confirmation of a successfully completed process.

This kind of validation feedback assures the user that their work is done and celebrates the effort they’ve put in.

Validating user input and providing feedback about it give them an opportunity to correct the input. If it’s likely you’ll receive incomplete or incorrect information that is needed for your visitor to use your product, help them recover using this pattern.

Another convenient method to assist your user is to preserve all their input during and after validation. Imagine your user says their date of birth is a date in the future yet to pass. You might be tempted to validate the date of birth against the current date, show feedback that the provided date is in the future and therefore needs to be changed, and clear the provided date, asking them to type in a new one. It is likely easier, however, for your user to adjust the year by one digit from 2091 to 2001 than to start all over again filling out the day, month, and year. Preserve their data. You might then draw attention to which part is incorrect by highlighting the year visually and providing a specific message to review the year.

Use the validation feedback pattern when it’s important to you to have accurate data. For a newsletter, having a lot of fake signups on your list can be costly if you are paying an email service provider per email address.

Using the validation feedback pattern lets you increase the user’s confidence that they’ve taken the right action (positive feedback) or help them recover from errors (negative feedback). For clarity, provide your feedback as close in proximity and time as possible to the action the user took.

In addition to warnings, errors, and confirmations, one underappreciated form of feedback is a gentle suggestion that hints at better steps rather than prevents further progress. One instance where it can help is inspecting phone numbers. Validating international phone numbers is a notoriously difficult task due to the wild variation in acceptable formats globally as well as how people format their numbers when they provide them. When asking for an optional phone number, you might include a validation warning or suggestion when the user provides a number that looks like it might be wrong, encouraging the visitor to check it, but avoid showing a validation error that prevents task completion. The visitor can then proceed with a fake or badly formatted phone number, but you’ve prompted them to check it twice for their own benefit. For example, consider this message:

Enter your phone number to help fast delivery of your order.

Pattern: Social signup

From here, we learn that a social signup pattern uses integration with a visitor’s existing social media accounts to signup to a product without creating a new username or password, fast-tracking the signup process.

Now we know a good deal about social signups. As we progress through the book, we’ll learn more about how to put patterns like this into practice.

Pattern: Lazy signup

I’d also suggest exploring other onboarding patterns,¹¹ such as paywalls/signup walls. Something outside your initial ideas might be just right for your needs.

Great, now we know what a signup might look like and the kinds of design decisions we need to make. Next, let’s explore competitive analysis and learning from the best.

Pattern: Notifications

A notification is a message object that presents timely information, including alerts, errors, reminders, cookie warnings, and requests.

When you need to provide time-sensitive, contextual information to a user, use a notification that appears close to the user’s point of focus or current task.

Figure 2-26 shows an example of a notification.

In this example, the Commonwealth Bank of Australia shows an upsell notification immediately after finishing a related task (making a payment) and immediately below that task.

An important design decision for notifications is whether and how it can be dismissed. A simple rule of thumb is asking yourself, “If the user dismisses the notification, does the page still make sense?” For example, Semantic UI’s Nag ( https://semantic-ui.com/modules/nag.html ) notifications “are used to present a user with a one-time message which will persist until a user acknowledges the message. This can be used for providing notices like the site’s use of cookies, an important change to a site like a security breach.” In this case, you’ll need to make a note somewhere in your system when they’ve acknowledged and dismissed the notification, in a cookie, session, or user account records. Then don’t show the notification again.

Another consideration is if you’ll need consecutive notifications and if they should fade away automatically. For example, snackbars¹⁴ and toasts¹⁵ provide transient messages that automatically time out and disappear. Only one is ever shown at a time, removing previous messages as they appear.

Furthermore, should the notification appear the next time the page or screen is visited or when the user next logs in? Figure 2-27 shows an example of a notification presented when a user logs in.

This notification informs the user how cookies are used, what the user is agreeing to, and where to learn more or manage “Cookie Preferences.”

Containers for notifications

When presenting a notification, you’ll likely need to pair it with a content container pattern.

For a task-specific notification, consider an inline panel, such as Foundation’s Callout¹⁶ or Bootstrap’s Alert,¹⁷ immediately next to the task itself. Figure 2-28 shows an inline panel related to the task that was just completed.

For messages that extend to the entire system or are likely to stick around after returning to a page or screen, use overarching screen elements, such as Foundation’s Sticky navigation¹⁸ or Bootstrap’s fixed Navbar.¹⁹ Figure 2-29 shows a fixed notification at the top of the page.

When triggering an alert according to some user action like logging in after an extended period, try overlay components, such as Spectre’s modal,²⁰ Semantic UI’s dimmer,²¹ Bootstrap’s popover,²² or Foundation’s tooltip.²³ Figure 2-30 shows a modal containing a notification after logging in.

Using one visual style for all of your notifications lets you establish a cohesive and predictable experience for your customers or visitors. On the other hand, adapting notifications to more precisely fit in close proximity to their trigger can provide more clarity. When a notification appears near the action that triggered it, the relationship is clear, and the user can figure out what steps to take next. The value of these trade-offs varies—as you might expect—by product or web site.

If there’s complex information needed to understand or resolve the notification, include links to further information or a reference of where to find this information in the future. Figure 2-31 shows an error that might be confusing to some people.

Next to the form field, there’s a link labeled “What’s this?” to learn more, as well as supplementary text below the form elaborating on how to find the data needed to enter into the form and proceed.

In most cases, you’ll want to include a clear call to action in your notification, such as a button to acknowledge the message (“Got it!”), a button to enable permissions (“Turn on notifications”), or a link to a task to take further action (“Go to Your Account Settings”).

Pattern: Good defaults

Good defaults for any information a user might need to provide can make it easier or faster for the user to provide it.

Figure 2-32 shows an example of replying to a message using a single button tap of one of three possible pre-canned messages, taking the hard work out of composing a response.

For onboarding new users to an interface, use good defaults that demonstrate value, like delighting users with examples of the most common use case for the product. For example, a photo sharing site could use selfies. Similarly, to avoid boring empty states for new users, use placeholders that illustrate how the interface might look after the user refines it with their personalized choices. One option is to pre-fill applications with sample items and guide the user on how to interact with them as we saw in playthroughs.

Good defaults require some understanding of what data has a better than even chance of being selected, so user research is important here. You might use defaults chosen from data provided by the majority of existing users to pre-fill empty fields. In other cases, you could pre-fill empty fields using existing data known about the current user, such as their location (determined using IP address), screen size, time they are using the site, and so on.

Good defaults are especially helpful when a new user has empty data sets or other empty states—avoid blank slates that paralyze users with ambiguity because they don’t know where to start.

You can also use good defaults when requesting information, including for any form, to make the process of providing information faster. Balance this with the tendency for people to skip fields that look complete already. You could do this by asking for confirmation or visually treating it as incomplete. Skip using good defaults completely if there are negative consequences for a field being incorrect and overlooked. For example, a phone case size selector could default to “iPhone X” because it’s the most popular choice, but the user still needs to consciously choose the correct size to match their phone or risk costly returns processes when receiving the wrong case.

Pattern: Coachmarks

A coachmark is instructional overlay content placed close to new features to help new users learn difficult interfaces.

For example, see Pinterest’s first-use animated coachmarks, shown in Figure 2-33.

Pinterest would highlight new features in blue until the user had tried them, as you can see in Figure 2-34.

This uses motion to draw your attention and a blue outline to highlight its newness, separating it from other, existing features. This style goes away as soon as you’ve acknowledged the feature.

To use coachmarks effectively, show tiny snippets of microcopy near important features to draw user’s attention and explain and visually indicate the “modality”—that is, indicate whether or not interaction with the coached feature will be impeded by the coachmark until you’ve dismissed it. You can use a transparent overlay over the rest of the page. You might consider automatically dismissing the coachmark when the user is interacting with the page. Figure 2-35 shows an example of how LinkedIn introduced people to the Enter key behavior in messages using a coachmark.

Because coachmarks draw attention, use them in moderation (don’t fill the page with coachmarks). Only use them when new users need assistance but providing the content inline would hamper the majority usage by return users. Figure 2-36 shows an example of a coachmark for introducing a new feature that only needs to be explained once.

It would likely be unnecessary to clutter the interface with that explanatory text all the time, so it can be reserved for a coachmark.

Coachmarks and walkthroughs can be tricky. Imagine installing an app on a new device, logging into the same account as usual, and being forced through a lengthy collection of coachmarks explaining features you’ve used a thousand times before you can use them again. This is an opportunity for interface reduction. For any user account notifications, record the user’s acknowledgment of the message when they dismiss it, and never show it again. Figure 2-37 shows a notification that would be superfluous for many repeat visitors.

Pattern: Progressive disclosure

A previous version of Apple’s MacOS Human Interface Guidelines defined Apple’s “User Control” design principle as “The principle of user control presumes that the user, not the computer, should initiate and control actions.” Further, Apple described progressive disclosure as “hiding additional information or more complex UI until the user needs or requests it” to “help you provide the right level of user control.”²⁵

For example, see MailChimp’s disclosure element ( https://ux.mailchimp.com/patterns/forms#disclosure ) shown in Figure 2-38.

To progressively disclose information, hide the extended information by default and provide a trigger that lets the user activate visibility of the hidden content, such as a link. After activation, bring more content into view in direct proportion to the user’s desire for more content.

Use progressive disclosure when most users do not need all the information and some users will need more information at some point in time.

Pattern: Staged disclosure

Similar to progressive disclosure, staged disclosure presents additional information in steps (or stages) according to the user’s direct request. In contrast, however, staged disclosure refers to a linear flow tunneling through a larger process. It advances the distance through a process rather than the depth into optional information.

For example, see Apple’s iPhone 8 product selection flow that provides three steps—choosing model, finish, and capacity shown in Figure 2-39.

This pattern is commonly used in signup, setup, purchase flows, and workflows.

To stage disclosure of information, chunk extended information into smaller, logical groups and present one at a time. Similar to progressive disclosure, provide a trigger to navigate to the next step, but also back links as needed, and consider pairing staged disclosure with a progress indicator.

Use staged disclosure when providing all the information at once would be overwhelming—focus users on one task or piece of information at a time.

Figures 2-40 to 2-44 show Dropbox’s staged disclosure for introducing two-factor authentication concepts.

Pattern: Progressive reduction

Finally, in contrast to progressive disclosure, rather than expanding on information as a user needs it, progressive reduction is the practice of reducing detail as a user no longer needs it. Expert users of an interface—loyal, repeat visitors, power users, subject matter experts, specialists—can learn an interface and no longer want the additional help provided to new users. You might reduce coachmarks and help tips after first use or start shrinking and removing labels on buttons. Expert users no longer need training wheels so stop cluttering the interface is with unnecessary information.

To progressively reduce information, remove coachmarks, tutorials, and feature explanations when they are no longer needed and help the expert focus on new content. Restore these extras when the user has not accessed the feature recently. Provide explicit user-initiated links to reduce interface noise, such as “Skip tutorial,” “OK, got it,” “Not now,” “Later | Close,” and “Hide this.” You might consider pairing progressive reduction with a temporary notification (as described previously) or an inline hint ( http://ui-patterns.com/patterns/inline-hints ) to indicate where the content may be found in the future, such as a reference guide or user settings. Alternatively, progressively reduce the visibility of features based on recency and frequency of use alone, without intervention from the user. This takes control away from the user, so use with caution.

Use progressive reduction when expert users get tired of seeing the same messages that they no longer need, specifically when the user has recently and frequently engaged with a feature.

I think a direct comparison between progressive disclosure and reduction means that the reduction should directly support the user’s level of control—it should be user initiated. Slack, for example, automatically turns off email notifications for new users when they turn on push notifications to the mobile app. Technically this is not user initiated but system initiated. Slack does, however, provide a link to the user’s settings, so they may turn the emails back on if they wish. They delicately walk the line of giving the user control as well as making smart guesses at actions to take for the user.

Finally, my favorite example of progressive reduction is apps remembering windows I’ve collapsed and hidden in the past to let me clear up the interface and focus on my task uninhibited.

Pattern: Login form

A login form (or sign in) asks for an identifier, such as a username or email address, and authentication information, usually a password, to access a user account containing private, personalized information.

Figure 2-45 shows an example of a login form, asking for an email address and password.

Show a login form to visitors when they need to access their content, either right before performing an action that needs an account (such as following or friending a person) or when directly accessing a “log in” link. When a user submits the login form, you need to check their details, and if they are incorrect, show validation feedback and help them recover—it’s common to include a password recovery link in a login form. After successfully logging in, return the user to the content they requested before presenting the login form.

Using an email address as a username is an effective usability hack that’s extremely memorable. It also doubles as a unique identifier for the account and a communication channel, so you may contact the user about the account. In this way, a telecommunications company might use a phone number as a username to minimize the number of details the user needs to remember. Alternatively, an identifier could also be a socially recognizable username like a twitter handle, for example, @lara_hogan.

Naturally, you won’t need to use a login form if you don’t have account registration or if you use the social signup pattern where you’d need to connect to another service instead.

Example: Redesigning a login form

Given the task of redesigning an existing modal, you can explore the modal pattern to inform your design.

Figure 2-46 shows a fictional login form.

From the pattern

From the details of the login form pattern we’ve just seen, we can see that we have design decisions to make about when to show the form, how to help people recover from errors, and what to use as an identifier.

Suppose the login form is for an information site that lets you save articles. When you save an article, you need to be logged in so that you can be shown that saved article again in the future. So we’ll add some details. Figure 2-47 shows an amendment to include the text, “To save this article, you must sign in to your account.”

Now you can see why you need to log in to your account and that you can tap a closing “×” to leave.

To help people recover from errors, we’ll add a password reset link (“Forgot password?”), as shown in Figure 2-48.

Finally, for a login identifier, we’ll use email address. Figure 2-49 shows “Email address” for the form field label and placeholder text, “e.g. jane.smith@example.com”.

Pattern resources

By researching our pattern resources, we find a few UI frameworks suggest a “Remember me” checkbox to help users stay signed in. Figure 2-50 shows the new checkbox.

This approach can help users avoid frequently needing to log in. There’s a risk though if your users are accessing your product on shared devices, such as in a university, library, or corporate network: other people may see their content when they leave the device. For this example, we’ll assume the majority of users are accessing the product privately on their own personal devices.

Searching for patterns

To learn more about the login form pattern, we could look for “login” or “sign in” to expand our results. By searching for “login form best practices,” you can find 3 Rules for Painless Account UX: Login by Jessica Enders ( www.sitepoint.com/3-rules-painless-account-ux-login-screens/ ), which suggests changing “Remember me” to tell the user exactly what will happen. For example, “Stay signed in on this device.” Figure 2-51 shows update text for the checkbox label, “Stay signed in on this device.”

Our login form is complete.

Competitive analysis

For competitive analysis, we might consider Medium, as it’s a high-traffic web site that lets you save articles. Interestingly, Medium shuns the login form pattern in favor of password-free accounts using email ( https://blog.medium.com/signing-in-to-medium-by-email-aacc21134fcd ), as shown in Figure 2-52.

When you need to sign in, Medium will send a magic link to your email address, as shown in Figure 2-53.

This means that your email account becomes the main point of failure for security. For our example, we’ll stick with the simple login form.

Innovation can occasionally make patterns redundant, so maybe in the future login forms won’t exist anymore.